IBIS Macromodel Task Group Meeting date: 10 July 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki * Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send an email to ATM announcing the DDR thresholds discussion topic. - Done. - Mike L. to update the IBIS 6.1 known issues list to include adding Value entries to the PAM4 thresholds Usage Out example on pg. 235-236. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 26 meeting. Mike L. moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Upgrading the input thresholds/measurement info to include eye diagram specs: - Walter reviewed the discussion of the topic, which was untabled and discussed at the previous ATM meeting and the Open Forum meeting on June 29th (also see Walter's "DDR4_BIRD_Requirements.pptx" posted to the IBIS Open Forum Meeting Minutes page 2018-06-29). Walter noted that slew rate rules in DDR4 or DDR5, for example, can be relatively complicated not just a few numbers. It could be very useful to put them in an "include" file instead of repeating them in every model. One basic IBIS Model (I/V tables, etc.) might work for many speed grades, but each speed grade might have different slew rate rules. It would be useful to avoid copying the same Model over and over just to add different speed grade information. Arpad noted that another possible solution was to have something scoped at the [Component] level instead of using include files. Walter said we could debate the optimal solution later, but first we had to get broad agreement that this was worth pursuing. Arpad agreed it was worth pursuing. Bob asked how the floating Vref definition would be defined in IBIS. Walter noted that the Vref is typically determined by the simulation waveform itself. You create an eye diagram and pick a Vref that maximizes the mask area. Ming asked if something like speed grade selection could be handled with a Model_Selector. Walter noted that Model_Selectors typically already contain lots of Models for different ODT values. Extending that technique to cover speed grade, etc., would lead to further multiplication of the combinations. Arpad said the proposal to add this capability makes sense. Parts are made and operate in this way, so we should be able to model it. Bob noted that he was in favor of it too but hoped it didn't get too complicated. Bob noted that he was worried about having to constantly upgrade the IBIS spec to keep up with new standards. Randy noted that what's nice about this proposal is that EDA vendors can implement all the various parameters, but it's nice if the information is in the model so the model maker can tie sets of parameters to a given model. This makes it clear to the user which speed grades, etc., a model can support, instead of them having to rely on info and readme files. Arpad noted that earlier discussions of proposals similar to this had leaned toward referencing external specs/sources not defining our own parameters for everything. This concept had been relevant to the BIRD147.6 (Back-channel support) discussions, for example. Walter, Bob and Arpad agreed in principle with this approach. Suggested outline included: 1. A new keyword to provide the specification name (perhaps IBIS would document reserved specification names). 2. A list of the Subparam names that applied for particular specifications. 3. Allowing the user to select speed grade, etc. (various Subparams) Bob noted that he would strongly suggest we adopt the formal specification names for any external specifications regardless of how long and unwieldy their official names might be. Arpad asked everyone to take an AR to come back with feedback at the next meeting. Clock forwarding in IBIS-AMI: - Walter noted that he had discussed this topic with Steve Parker of Global Foundaries. The application was similar to DDR5 in that it had a clock forwarding interface. Walter noted that some SERDES specs (PCIe Gen3) had also supported clock forwarding interfaces, though differential not single ended. Walter noted that the conclusion he had come to in his discussion with Steve was that if one wanted AMI modeling to support clock forwarding we would require a new BIRD. We would need a new mechanism for passing the clock ticks along with the data to the Rx. Walter said he advised Steve that he could either draft a BIRD himself or make a formal request to IBIS for such an enhancement. Arpad noted that the tabled topics list contained a topic related to various enhancements that might be necessary for AMI to extend to DDR5. Walter agreed and noted the DDR4/DDR5 parameters topic, clock forwarding, and asymmetric rise fall times. Arpad asked if we should untable the topic. Mike L. moved to untable the "Single Ended Applications of AMI modeling" topic for the next meeting. Bob seconded. There were no objections. Arpad said he would fold this "clock forwarding" topic into the "Single Ended Applications" topic. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 17 July 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives